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ABSTRACT 



Apparatus and process are disclosed by which to disable a 
computer's access to all or a part of the computer's memory 
system or associated peripherals, so as to protect the com- 
puter from accidental or malicious damage of data files or 
programs that may result from the activity of computer users 
or computer viruses. This result is achieved by providing the 
authorized user with a token whereby the user can configure 
the security gateway to completely or partially disable the 
peripheral device without disrupting the operation of the 
computer or other peripherals. The principal hardware com- 
ponent of one embodiment of the invention is the security 
gateway which in a typical configuration simply adds new 
security functions to the programmable controllers that are 
typically used for an I/O controller or hard drive controller, 
although this is not always necessary. The process can just 
as easily be incorporated into a local network controller, a 
communications controller, or a main processor board for a 
system. The speed of the security gateway can be further 
enhanced by adding additional computational or encryption 
hardware to the chip sets used in said I/O or hard drive 
controllers. 

23 Claims, 1 Drawing Sheet 
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NETWORK SECURITY SYSTEM ALLOWING 
ACCESS AND MODIFICATION TO A 
SECURITY SUBSYSTEM AFTER INITIAL 
INSTALLATION WHEN A MASTER TOKEN 
IS IN PLACE 

CLAIM OF PRIORITY BASED ON CO- 
PENDING PROVISIONAL APPLICATION 

The present application is related to co-pending Provi- 
sional Patent Application Ser. No. 60/053,122 filed Jul. 18, 
1997 entitled "COMPUTER AND NETWORK SECURITY 
SYSTEM", and based on which priority is herewith claimed 
under 35 U.S.C. §119(e) and the disclosure of which is 
incorporated herein by reference in its entirety. Likewise, the 
disclosure of Disclosure Document 422490 filed Aug. 11, 
1997 is also incorporated herein by reference in its entirety. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

This invention relates to apparatus and methods for com- 
puter security and to the prevention of unauthorized reading 
or altering of computer data by individuals or programs 
operating on a computer or a computer network. 

2. Description of the Prior Art 

This invention addresses two major areas of computer 
security for both individual computers and networked com- 
puter systems: (1) protection of programs and data at the 
place where they are stored, and (2) secure exchange of data 
and programs between computers and computer users. 

Protecting computer data and programs from unautho- 
rized copying, destruction, or alteration is a major concern 
for governmental agencies, businesses, educational 
institutions, and individual users. In addition to protecting 
valuable data from spies or malicious programmers, there is 
a need to protect data from computer "virus" programs 
which can infect a system and cause damage at some later 
date. Numerous computer security programs have been 
written to provide a large variety of features to protect 
computer data. These include such features as password 
protection, restricted access to specified files, limited menu 
options, checksum verification, and scanning for known 
virus programs or virus-like activities. The major shortcom- 
ing of these computer security programs is that they must 
operate within the computer* s working memory space, its 
RAM. This means the security software is susceptible to 
other forms of software which can defeat the program's 
security measures. 

Software protection of computer data can be enhanced by 
the use of specialized computer hardware that provides 
additional security functions. In U.S. Pat. Nos. 5,144,659 
and 5,289,540, Jones teaches a security method wherein a 
hard drive controller provides extra security functions. In 
U.S. Pat. No. 5,434,562, Reardon teaches the use of CPU- 
independent, user activated key lock switches by which an 
CPU-independent security controller can be configured and 
reprogrammed in a secure fashion. These inventions illus- 
trate a method of enhancing security by making some 
security functions independent of the CPU. In Reardon's 
invention, these hardware secured parameters require a user 
to insert and activate a CPU independent hardware switch to 
change or alter the security parameters. Since this switch is 
CPU independent, it is impossible for this hardware security 
device to be bypassed or defeated by software or keyboard 
programming. 

The second major area of concern in the field of computer 
security revolves around the area of secure communication 
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in the exchange of data. This field of security requires an 
ability to encrypt data, to limit access to intended persons, to 
verify the accuracy of transmissions, and to verify the 
identity of the sender. One popular technique employs the 

5 use of asynchronous encryption keys. This technique is 
based on the use of public/private key-pair encryption 
system wherein two binary strings (one serving as a "public 
key" and the other as a "private key") are used to encrypt and 
decrypt data. Anything encrypted with one key can only be 

10 decrypted by the other. The public key is "published" or at 
least accessible to intended recipients of data. The private 
key is never revealed but is held only by owner of that key. 
To send a private message, the sender encrypts a message 
using the receiver's public key. Since only the receiver 

15 possesses the matching private key, only the receiver can 
decrypt the message. 

To send proof of one's identity, the sender encrypts a 
message using his own private key. This message can only 
be decrypted using the sender's public key. Thus, any 

20 receiver who has access to the public key can verify that the 
message was sent by the person who possesses the matching 
private key. In this way, the receiver can use non- 
confidential information, the public key, to verify that the 
sender possesses the corresponding private key, thus con- 

25 firming the identity of the sender as that corresponding to 
public key. 

Many additional cryptographic techniques, well known in 
the art, can be used to enhance this general scheme. For 
example, proof of the identity of the party associated with a 

30 public key can be certified by a private or governmental 
authority who issues said party a an electronic "Digital 
Certificate." Also, the integrity of data transmissions can be 
verified by the use of "hashing" formulae that create a short 
message digest similar to a check sum. In these ways, for 

35 example, financial transactions and the like can be 
electronically, securely, and and privately transmitted to the 
intended party (using the receiver's public key), including a 
digital signature (using the sender's private key), verifica- 
tion of the sender's of identity (using a Digital Certificate), 

40 and verification of the message content (using the hashed 
message digest). To guard against the accidental loss of a 
private key, or to recover corporate data in the event of a key 
owners death or disability, private keys can be split into 
multiple parts that are placed in "escrow" with two or more 

45 separate parties. In the event of loss or disability, the escrow 
agents can provide to the authorized receiver their escrowed 
portions of the key so that it can be reassembled and used to 
recover files encrypted with its associated public key. These 
and other encryption techniques, known to those skilled in 

50 the art, can be implemented with the present invention. 
The use of asynchronous keys, or public/private key pairs, 
has been further enhanced by the use of portable electronic 
devices, often referred to as "tokens," that store the asyn- 
chronous key in electronic memory and protect it from 

55 unauthorized use by means of a personal identification 
number (PIN). Tokens may include both memory for storage 
of keys and encryption processors for encrypting data. These 
technologies make the private portion of the asynchronous 
key pair more secure because it does not reside on the 

60 computer where the data is created. In addition, the token 
can be easily transported, like an ID card. The "key" to the 
data can therefore be stored away from the data, thus 
enhancing security. To access files encrypted using the 
owner's public key, a corporate spy would need to (1) gain 

65 access to the encrypted files, (2) find and steal the token and 
(3) discover the owner's PIN which makes the token func- 
tional. 
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One disadvantage of the encryption tokens described 
above is that they are relatively expensive because of the 
substantial electronics required for each token. In addition, 
while these tokens provide excellent security in the 
exchange of data, they cannot directly protect the storage 
area where the data is stored from being erased or altered by 
computer viruses or sabotage. 

It was with knowledge of the foregoing disclosures rep- 
resentative of the state of the art that the present invention 
was conceived and has now been reduced to practice. 

SUMMARY OF THE INVENTION 

This invention describes a means and process by which to 
disable a computer's access to all or part of the computer's 
memory system or associated peripherals, so as to protect 
the computer from accidental or malicious damage of data 
files or programs that may result from the activity of 
computer users or computer viruses. This result is achieved 
by providing the authorized user with a token whereby the 
user can configure the security gateway to completely or 
partially disable the peripheral device without disrupting the 
operation of the computer or other peripherals. 

The present invention has hardware and software ele- 
ments that are well known and utilized in the field of 
computers and computer security. The present invention, 
however, combines these elements in a novel manner unlike 
any other system known to produce useful benefits, 
increased security, and reduced costs of manufacture. 

The principle hardware component of one embodiment of 
the invention is the security gateway, which in a typical 
configuration simply adds new security functions to the 
programmable controllers that are typically used for an I/O 
controller or hard drive controller, although this is not 
always necessary. The process can just as easily be incor- 
porated into a local network controller, a communications 
controller, or a main processor board for a system. The speed 
of the security gateway can be further enhanced by adding 
additional computational or encryption hardware to the chip 
sets used in said I/O or hard drive controllers. 

With regard to the software elements of this invention, 
computer programmers will immediately recognize many 
ways to implement security software that can employ the 
features of the configuration switch disclosed in this inven- 
tion. Commercial security programs that allow user 
configuration, but lack a hardware security gateway and 
token based configuration include Pro tec by Sophco, Total - 
safe by EliaShim, and Cetus by Foundation Ware. U.S. Pat. 
No. 5,144,659 to Jones discloses a detailed flowchart for 
software configuration of a CPU-independent, program- 
mable security device for hard drives, though the Jones 
invention lacks the user accessible configuration switch of 
the present invention and the use of a token as described 
herein. 

The present invention provides a security gateway that 
operates by intercepting the system data path, address bus, 
and control logic signals between the CPU and peripherals, 
such as hard drives and network communication cards. The 
requested operation is processed according to the criteria 
established by the security gateway's preprogrammed secu- 
rity parameters. These security parameters may be unique 
for each individual using the computer or computer network. 
The security gateway generates a unique asynchronous key 
pair for each user and creates a token containing the private 
key for that particular user that is encrypted with the security 
gateway's own public key making the token readable only 
by the security gateway. More complicated techniques are 
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also disclosed for creating a token that can be used through- 
out a computer network. 

The appropriate security parameters and access rights are 
assigned to new users by the appropriate supervisory and/or 
security personnel and are associated with the token that is 
issued to the new user. Assignments of rights, or modifica- 
tion of rights, can only take place after the identities of said 
supervisory and/or security personnel have confirmed by the 
security gateway's examination of their own tokens and only 
under such additional conditions that may previously have 
been defined. 

After the security gateway has read a token, confirmed a 
user's PIN number, and determined the user's rights, the 
security gateway will refuse to allow the user any access to 
any restricted peripherals or portions of said peripherals. 
Otherwise, the security gateway will be "transparent" to the 
user and computer system. 

In addition, the security gateway can monitor a computer 
system's initialization process and monitor the integrity of 
any CPU based security software. Furthermore, the security 
gateway's tokens can be used for all the functions of secure 
data communications that are commonly used in public key 
cryptography. It should be noted that while the encryption 
and decryption of the U.X key stored on the token must be 
performed by the security gateway itself, when using the 
token for secured communications, the main message could 
be encrypted by the CPU using any of many encryption 
techniques. Only the message encryption key would need to 
be encrypted by the security gateway using U.XR (see 
definitions to follow). This point is important because the 
packets of information that must be encrypted or decrypted 
by the security processor would normally be relatively 
small. In most applications, the larger files could be 
encrypted using the greater processing power of the CPU. 

Furthermore, the security gateway of the present inven- 
tion can monitor the integrity of program files and imple- 
ment a single site licensing protocol that can prevent the 
transfer and use of licensed software to other computer 
systems or limit the use of software to a specific period of 
time or number of trials. 

A distinct advantage of the present invention over the 
prior art is that it combines the data security features with 
modern encryption techniques in a way that produces new 
and unexpected advantages in terms of both cost and func- 
tionality. This invention improves on techniques previously 
disclosed by Reardon in U.S. Pat. No. 5,434,562 by elimi- 
nating additional manufacturing costs, provides greater flex- 
ibility for third party software developers, and a provides a 
means for generating unique asynchronous key pairs for the 
authentication of an individual user's identity, secure data 
transmission, and rights access. 

An object of the present invention is to provide apparatus 
and methods by means of which the authorized user of a 
computer can protect data and programs stored in peripheral 
devices, such as mass storage media, from alteration or 
deletion by malicious persons, or computer "virus" 
programs, or accidents initiated by unskilled persons. 
Another object of the present invention is to provide a means 
and method for verification of identity of users and encryp- 
tion and authentication of data transfers. 

This invention is particularly useful in multi-user envi- 
ronments. This invention is also useful for persons who 
desire to evaluate new software but are afraid that by doing 
so will they will be exposing their computer system to 
infection with a computer virus. By locking out write access 
to their computer's hard drive, the system is "safe" and the 
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suspect program can be run without risk of it causing an CPU: The Central Processing Unit (CPU) is one or more 

infection which may later cause loss or disruption of pro- computer programmable devices that serve as the primary 

grams and data. processing center for computer implementation of program 

By providing complete user control over a computer's instructions, computation, and transfer of information, 

access to its peripheral devices, this invention allows the 5 CPU Security Program: Program and associated files that 

user to implement greater security precautions against unau- are im pi eme nted by the CPU to monitor system security, and 

thorized programs or users. These options mclude limiting enforce securit restr i c tions for the system or individual 

read and write access to the peripheral device, and the ability users 

to configure the peripheral device so as to make all or , _ . , . , r . , 

c .l j ■ * * j * Digital Certificate: A binary information file that can be 

portions of the device appear to the computer as a read-only, in ' , , ' , , , r , 

% 1 ^ „ * 1 a~„-„~ IU verified as issued by a trusted authority by use of the 

write-only, or write-once peripheral device. . , , J . 

. - ' , . , c iL 4 . . . 4 ., certifymg authority s pub he key where the certifying author- 

A further obiect of the present invention is to provide J ? f « • c ** f • j • 

v , j j 1 • , 1 lty vouches for some or all of the information contained in 

computer security apparatus and methods wherein tokens / ~. . A , ~ . ~ . „ p.. . , ~ . a t 

j . . the Digitai Certificate. Typically, a Digital Certificates may 

can be easily and inexpensively created and issued to as , c 1 • 1 j 11 i n- •! 1 r. -»-c . L 

J , . , r . , , in fact include several layers of Digital Certificates, each 

many users as desired with customized rights for each user. 15 , e 4U , J , .\ ™. . , 

* _ t ... . . layer vouching tor the layer beneath it. This is known as a 

Still another object of the present invention is to provide Certification Hierarchy. For example, at the highest level the 

a computer security apparatus and methods wherein tokens ^ post Master > s public key ^ ^ verify that the 

can be restricted for use at a single computer or configured encbsed Digilal Certificate n was to the local 

to operate on selected computers within a network. Metropolis post office. The public key of the Metropolis post 

A still further object of the present invention is to provide 20 office ^ used t0 that the Metropolis post-master 

a computer security apparatus and methods wherein modi- the enc i osed Digital Certificate #3 to the ABC cor- 

fications to rights and restrictions can be implemented offsite p0 ration. The pubhc key of the ABC corporation's is used to 

by a security supervisor under more secure conditions and certify that the corporation issued Digital Certificate #4 

wherein a security gateway can be easily programmed to t0 John Doe in ABC's accounting department. Each certifi- 

block the installation or use of programs that are not 25 cate would contain information about the public key and 

approved for use on a computer system or computer net- identity to whom the certificate was issue, a certificate serial 

wor ^* number, certificate validity dates, and the certifying authori- 

Other and further features, advantages, and benefits of the ties I.D. information and digital signature, and any addi- 

invention will become apparent in the following description , tional information as may be required. All of the Digital 

taken in conjunction with the following drawings. It is to be 30 Certificates described in the above example can be contained 

understood that the foregoing general description and the i D a smg i e Digital Certificate that is sent to Bill Smith of 

following detailed description are exemplary and explana- XYZ, Inc. By examining these Digital Certificates, Bill 

tory but are not to be restrictive of the invention. The Smith can now evaluate the certainty of John Doe's identity 

accompanying drawings which are incorporated in and based on the his trust in the hierarchy of certifying authori- 

constitute a part of this invention, illustrate one of the 35 t j es Thereafter, the Bill Smith can use John Doe's public 

embodiments of the invention, and together with the k ey t o privately and securely communicate with John Doe 

description, serve to explain the principles of the invention us i ng the widely known methods of public key cryptogra- 

in general terms. Like numerals refer to like parts throughout p ny 

the disclosure. Gateway Program: A program and associated files that are 

BRIEF DESCRIPTION OF THE DRAWINGS 40 implemented by the security gateway to monitor system 

A . , * c * * security, and enforce security restrictions for the system or 
FIG. 1 is a schematic block drawing of a computer system 

1 • , • • 1 c *l • * *• *u * individual users, 

according to the principles of the present invention that . . . 

illustrates the relationship between the CPU, the security Ke ? Pair: A complimentary pair of encryption keys 

gateway, the token reader, and peripheral devices that may 45 whereby a Wlth <"« P art can °^ be 

be subject to security restrictions implemented by the secu- decrypted by the other part. This is also known by those in 

rity gateway; and lhe art ^ an as y ncnronous kev P air or as a public key 

FIG. 2 is a functional block diagram illustrating the cryptography, 

elements of a security subsystem for the present invention. Non-volatile memory: Memory locations that preserve 

5Q their stored information even when power has been removed 

DETAILED DESCRIPTION OF THE from the memory banks and/or computer system. Typical 

PREFERRED EMBODIMENTS examples of non-volatile memory include ROM, EEPROM, 

In the ensuing description of the present invention, the Flash memory devices, and magnetic storage media, 

following definitions will be utilized: PIN: Personal Identification Number. This can be any 

Block Encryption: An encryption method that uses a 5S password associated with the user of a token to prevent the 

single key for both encryption and decryption and that token's unauthorized use by a person who does not know the 

encrypts groups of bits rather than a single bit at a time. PIN. 

Bus or "host computer bus": The electronic paths within Private Key: The part of a key pair that is reserved by the 

the host computer that carry address, control, and data "owner" of the key pair and not disclosed to any other party, 

signals. As used herein, the term "bus" should be considered 60 Public Key: The part of a key pair that is shared with 

to also include any alternate means of data interface with the parties with whom the owner desires to exchange files. 

CPU and other internal or external devices. A fiber optic Restricted Memory: Non-volatile memory which is acces- 

system could be one such alternative. sible only to the security gateway. This may include reserved 

Computer virus: Any potentially destructive computer sectors of the hard drive and tokens to which the GATEWAY 

program that may cause malfunction of the computer, cor- 65 PROGRAM will never allow access requests from the CPU. 

ruption of files, loss of data, or other unwanted and unex- For backup purposes, restricted memory can be encrypted 

pected results. using SG.OR prior to transfer to backup media. 
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Security gateway: A programmable device that is inde- 
pendent of the CPU and situated in such manner as to be able 
to control or block the CPU's access to secured peripherals 
such as mass memory storage devices, network communi- 
cations devices, and the token reader. This device would 5 
include sufficient nonvolatile memory and random access 
memory for implementation of its functions. 

Shell: A security program consisting of two parts, a CPU 
Security Program and a Gateway Program, wherein each 
part works with the other to enhance the total system 10 
security. 

SSL: Single Site Licensing protocol used to prevent 
unauthorized use or duplication of software or data. 

Token: A removable memory device capable of storing 
one or more encryption keys. This token may be as simple 15 
as a magnetic strip or as complex as a PCMCIA card, 

Token Reader: An input device by which means the 
security gateway can read the information encoded on a 
token. 

Definition of Key Names: 20 

In the specification that follows abbreviations are used to 
specify particular key pairs and, when appropriate, the token 
associated with the private portion of the key pair. The SG 
prefix refers to a Security Gateway related key. The U prefix 
refers to a key that is assigned to an individual user, and SSL 25 
refers to a key that is issued to parties in a single site 
licensing of software. The prefix CA is used by a Certifying 
Authority that issues a Digital Certificate. Since multiple 
keys may be involved for each party, each prefix is follow 
by a decimal point and a number identifying which key pair 30 
is being referred to, and either the letter R or B where R 
refers to the private portion of an asynchronous key pair and 
B identifies the public portion of the key pair. 
AK.l — A key pair used by a certifying authority to assist in 
anonymous but traceable transactions wherein the anony- 35 
mous user's identity and Digital Certificate is sealed with 
AK.1B. AK.1R is divided and placed in escrow so the 
anonymous users Digital Certificate and identity can be 
recovered, with proper authorization such as a court order, 
in the event there is a subsequent criminal investigation or 40 
civil dispute. 

CA.l — A key pair used by a Certifying Authority to verify 
that some or all of the information contained in a Digital 
Certificate encrypted with CA.1R has been verified the 
Certifying Authority, 45 

CS.l — The security gateway key pair of the central server of 
a computer network, 

SG.O — A key pair belonging to the security gateway manu- 
facturer. SG.OB is factory installed into the security 
gateway. This allows for authentication of manufacturer 50 
upgrades of the security gateway's and SSL standards. 
The upgrade may include the issuing of a new public key 
for the manufacturer. For authentication purposes, the 
upgrade must by verifiable by including one or more files 
encrypted with SG.OR. 55 

SG.l — The security gateway's own key pair, generated 
upon activation of the security subsystem functions. This 
key may be generated using site specific "seed numbers." 
A corresponding Digital Certificate may include user ID 
and site identification information. 60 

SG.X — The security gateway key pair of computer other 
than the one that created a particular token where X is a 
number identifying the security gateway and host com- 
puter. 

SSL.l — A file on the original diskette of an SSL protected 65 
program or data set. This file contains the SSL protected 
program's Digital Certificate, including a "marriage" 
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history, and the file is flagged in a manner such that the 
security gateway will not allow it to be copied to any other 
media. 

SSL.2 — A copy of SSL.l which is embedded in the software 
and can be freely copied with the program to the hard 
drive or backup diskettes. 
U.O — The master configuration key for the security gateway 
held by User 0, where User 0 is the person chiefly 
responsible for configuring the computer's security. In 
addition to any other necessary information, U.0R is 
stored on the MASTER TOKEN in a file encrypted with 
SG.1B. U,0B may be stored on the hard drive or even 
made available on a network if the MASTER TOKEN is 
intended to be used at other sites. 
U.l — A security gateway configuration key used for on-site 
confirmation of a network issued upgrade of the Security 
gateway security parameters. U.1R is stored on the on-site 
diskette in a file encrypted with SG.1B. 
U.X — A key for individual user number X. A U.X diskette 
contains a file which is encrypted with SG.1B that con- 
tains U.XR and any additional security information such 
as rights, passwords, and a Digital Certificate associated 
with the individual user. 
Returning now to FIG. 1 which illustrates in a broad sense 
one embodiment of a computer system according to the 
present invention. In the following description of the FIG. 1 
embodiment, file control functions will be discussed, and 
such basic control functions are described in U.S. Pat. No. 
5,289,540 to Jones. 

Because they are so well known and in such common use, 
the description of this invention will be based on the use of 
a personal computer (PC) using on operating system such as 
Windows 95 or MS-DOS. However, it should be understood 
that this, is done for the sake of convenience and simplicity 
of description and the invention should not be considered as 
limited to these or any other operating system or computer 
equipment. 

The system of FIG. 1 includes a control processing unit 
(CPU) 10, a security gateway 12, a token reader 14 for 
reading a user token 16, a hard drive memory 18, protected 
peripheral devices 20 such as network communications, and 
a common bus 22 for peripheral devices. 

FIG. 2 shows the functional elements of a security sub- 
system including a programmable auxiliary memory 30 and 
auxiliary control unit 32; file storage devices 34 for storing 
files, with at least one of the storage devices capable of 
reading and writing to removable storage media; means 42 
for attaching the security subsystem to the digital computer 
bus; means 36 for generating private/public key pair data 
and storing the private key data in a file location of the file 
storage devices 34 which is under the control of the security 
subsystem auxiliary control unit 32 and to which access by 
central processing unit 10 of the digital computer can be 
denied; means 40 for using the public key to create an 
encrypted key file which is written to a removable token, 
such that the encrypted key file can only be decrypted and 
authenticated by the security subsystem using the corre- 
sponding private key of the private/public key pair; means 
38 for permitting access to the security subsystem by the 
computer operating system for installation and modification 
of security requirements only when the removable token is 
placed into the appropriate file storage device and has been 
authenticated by the security subsystem; and by a combi- 
nation of these means requiring the security subsystem to 
deny file storage device and peripheral device access 
requests by the central processing unit when the security 
requirements are not satisfied. 
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It should be noted that in the interest of speed, much of the MASTER TOKEN that the buyer would used to customize 

encrypting can be performed using a faster shared key the security features of the computer. To initialize the 

algorithm (such as a Data Encryption Standard (DES) key) security gateway, 12, and setup the security parameters, the 

if the shared key is itself encrypted using the appropriate buyer or security supervisor would place the MASTER 

public or private key. The public or private keys, therefore, 5 TOKEN in the token reader, 14. Optionally, the manufac- 

merely serve as an authentication barrier to access of the turer could design the GATEWAY PROGRAM to require 

shared key. The shared key, of course, can be uniquely that the MASTER TOKEN be in place before the computer 

generated for each transaction. is powered up. The original manufacturer would include as 

In the embodiment of FIG. 1, the functions of the security part of the GATEWAY PROGRAM stored in restricted 

gateway 12 may be integrated into a hard drive and floppy 10 memory the key SG.OB, The MASTER TOKEN would 

diskette controller. Because most hard drive controllers include one or more files encrypted with SG.OR. By use of 

already use a programmable processor to implement various SG.OB the Gateway Program can verify that the MASTER 

functions, in many cases the functions of security gateway TOKEN is indeed a token issued by the manufacturer and 

12 could be added as additional subroutines in the firmware can be "trusted" as a secure device for initiating security 

of the controller without substantial hardware modification, is software or parameter changes. It should be noted that 

However, because encryption algorithms may be complex, SG.OB is never published in any public way. It would only 

additional memory and/or logic circuitry that enhances the leave the factory in firmware for a particular series of 

speed of encryption/decryption could be added, if necessary, security gateway devices. SG.OP would never leave the 

to prevent any degradation in speed. Because the security manufacturer's premises at all, except in a divided escrowed 

gateway 12 has control over one or more hard drives 18, it 20 form. As is true in many other uses of key pairs in this 

is most cost effective to reserve space on one or more hard invention, access to both the "public" and "private" portions 

drives for the security gateway's own use. For all practical of the key pair is strictly protected. Under no circumstances 

applications, the security gateway's ability to "leech" as would the GATEWAY PROGRAM ever transmit SG, OB to 

much memory space as it needs off of the system's hard another device, 

drive for its own purposes ensures that there is no practical 25 After determining that the MASTER KEY is in the token 

memory limit on the security gateway's program size or reader, the GATEWAY PROGRAM would scan the MAS- 

security parameters. Because these reserved sectors are TER KEY to determine if this is a first time use of the 

under the complete control of the security gateway 12, they MASTER KEY and examine the security gateway's 

would never be made accessible to the CPU 10 or the host restricted memory to determine if SG.l had already been 

computer's operating system. For added security, the infor- 30 created. If the GATEWAY PROGRAM determines by these 

mation contained in these sectors can also be encrypted with means that initialization program should be run, said pro- 

the security gateway's own public key (SG.1B). In this gram would be loaded into the CPU to provide a means of 

event, even if the hard drive was moved to a different interaction between the user and the security gateway. To 

computer, these reserved sectors would be indecipherable to enhance the security of this process, it would be advisable 

any device other than the security gateway that created them. 35 not to allow any other programs to be allowed to run during 

To provide a means of recovering these files in the event of any initialization or modification of security parameters. The 

a hardware failure, the public key could be divided and manufacturer could enforce this provision through subrou- 

placed in escrow with trusted authorities. For the sake of tines in the GATEWAY PROGRAM that would be imme- 

convenience, the security gateway's reserved sectors of hard diately obvious to any computer programmer, 

drive space will be designated with negative numbers. 40 Upon confirmation from the user that the first time 

In this typical example, upon the powering up of the initialization should proceed, the security gateway would 

computer system the security gateway, 12, would reads its request the user to enter personal information, PIN numbers, 

own factory installed GATEWAY PROGRAM from non- and initial security preferences. If desired for the purpose of 

volatile memory. It might also check for extensions to its added security, the new user can also be presented with 

GATEWAY PROGRAM on, for example, sectors -1 45 dozens of questions of a personal nature (such as the name 

through -5 of the hard drive. of one's first pet). These questions can then be randomly 

The GATEWAY PROGRAM and any extensions that may used as a secondary check after entry of a correct PIN to 

be installed contain the instructions and security parameters further verify a user's identity. The security gateway might 

that control the security related activities of the security also request additional information about the computer 

gateway. The GATEWAY PROGRAM can be either very 50 configuration and computer network from the user or 

simple or very complex, depending upon the needs of users directly from the CPU. After enough information has been 

and the marketing goals of manufacturers and security collected to construct a unique profile the security gateway 

software vendors. would use a hash or checksum of this "random" data to 

The token reader 14, is read directly by the security create a unique seed for use in generating SG.l, a key pair 

gateway 12. In a typical configuration, the token reader 55 that would be unique to this particular security gateway, 

could be a standard floppy diskette drive. Other devices can After SG.l has been created, the security gateway is distinct 

be used as a token reader, the only requirement being that the from all the other security gateway's produced by the 

device must be able to read and write to a removable manufacturer. Both portions of SG.l are stored in restricted 

memory device that can serve as a token 16. Because the memory locations. 

security gateway is interposed between the token reader and 60 Using SG.1B, the security gateway creates a file that is 

the CPU 10, information stored on the token is secure from stored, perhaps at a specific and predetermined location, on 

CPU access unless such access is specifically provided for the MASTER TOKEN. This SG.l encrypted file thereafter 

by the GATEWAY PROGRAM. In such cases, the security serves as a means of determining that the MASTER TOKEN 

gateway would echo the data reads and writes from the CPU has been configured. A PIN would be selected and encrypted 

to the token reader 14. 65 and stored on the MASTER TOKEN with additional secu- 

In a typical example, a new computer system would be rity parameters, passwords, certificates of authority, and 

shipped with a rudimentary GATEWAY PROGRAM and a other information that may be necessary for a particular 
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security needs. In addition, the security gateway would also Tokens can be created for each individual and also for 

create U.O, a key pair that is assigned specifically to User 0, specific applications. For example, a corporate accountant 

the owner of the MASTER TOKEN. U.OR would be stored might have two tokens. The first would be a general use 

on the MASTER TOKEN in an encrypted form using token that provides him with access to all the general 

SG.1B. U.OB would be stored in a restricted area. U.OR can 5 purpose programs he might need such as word processing 

thereafter be used as the private key of the MASTER and Internet access with the exception of access to the 

TOKEN holder and can be used for verification of identity, accounting books. The second token that gives him access to 

access to modification of security parameters, secured the accounting books might be separately stored under lock 

communications, and for personal file encryption. and key, thus providing an additional level of security. 

After this first initialization, the MASTER TOKEN can be no To preserve against the loss or destruction of any token 

used to reconfigure security parameters or to create new created by the security gateway, including the MASTER 

tokens for one or more users with rights either equivalent to TOKEN, the GATEWAY PROGRAM may include subrou- 

those associated with the MASTER TOKEN, or more tines that will take the information and keys stored on a 

commonly, with restricted rights. Every time the security token and divide them into multiple parts that can placed in 

gateway creates a new token, it would create a unique key is escrow onto multiple tokens. By use of these escrow tokens, 

pair U.X for the person to whom the token is issued, User X. the security gateway can reconstruct lost or destroyed 

U.XR and an associated PIN would be stored on the token tokens. SG.1R may also be divided and placed into escrow 

in a form encrypted with SG.1B. U.XB would be stored in to provide a means of recovery in the event the security 

the security controllers restricted memory or, if desired, gateway itself is rendered inoperative, 

"published" in a file accessible to the CPU or computer 20 Most ideally, the security gateway would automatically 

network. A Digital Certificate, security parameters, and sense when a token is inserted into the token reader and the 

other user specific information could also be incorporated security SHELL would automatically activate a window 

into encrypted files on the token. The specific rights and requesting the user to enter his or her PIN. Alternatively, the 

restrictions associated with each user can saved in the user can activate a program that instructs the computer to log 

security gateway encrypted files on the token, in restricted 25 on a new user. After confirmation of the PIN, the user could 

memory, or, in a network application, in a restricted memory be instructed to remove the token before allowing access to 

location of central server's security gateway. Once the token ensure that user does not forget to remove the token and 

has been created and a PIN and rights have been assigned, properly secure it. The security gateway can record multiple 

User X can thereafter use it for any and all security entries of the wrong PIN on the token and in other memory 

functions, including verification of identity, identification of 30 locations and either disable the token or sound an alarm if 

computer access rights, secure file communications, and the number of attempts exceeds a predefined security limit, 

personal file encryption. Additionally, the security gateway can "time out" a user who 

In a typical application, the User X would place the token, has not been active at the computer after a predefined period. 

16, in token reader, 14. The token reader would transfer These and other techniques commonly used in computer 

information from the token to the security gateway, 12, and 35 security can easily be made part of the GATEWAY PRO- 

verify the users identity by activating a subroutine that GRAM or SHELL. 

would allow the user to enter a PIN. After confirmation of The previous discussion has described the basic steps that 
the PIN, the security controller would determine the access are always required to implement any of the security func- 
rights of User X and limit the CPU's access to data and tions disclosed in this invention. Namely, (1) the security 
peripherals according to these assigned rights. Requests to 40 gateway must be initialized to create its own unique SG.l 
read or write to restricted files would be denied and might key pair; (2) A user specific key pair, U.X, must be created; 
also be recorded for reference by the Corporate Security (3) U,XB must be stored in a restricted area or "published" 
Officer or trigger an alarm. The GATEWAY PROGRAM can in a place other than on the token; and (4) U.XR and an 
also conceal the existence of any files or peripherals such as associated user's PIN must stored on a token, 16, in an 
peripherals 18 and 20 that are "downline" from the control- 45 encrypted file that can only be opened with SG.1R. 
ler and not directly on the CPU bus. By monitoring CPU bus It should noted, however, that while the encrypted files on 
address, data, and control signals, the security gateway can the token must be secured so that only the security gateway 
also detect if the CPU attempts any unauthorized reads or can open them by use of SG.1R, it is not necessary that they 
writes to peripherals on the CPU Bus, 22. While such actually be entirely and directly encrypted with SG.1B. 
peripherals cannot be protected in the same fashion as 50 Greater encryption speeds can often be achieved, without 
"down line" peripherals which have the security gateway loss of security, by the use of other encryption techniques, 
interposed between themselves and the CPU, the security One widely used method in public key cryptography 
gateway can still provide some protection for "up line" involves the creation of a "lockbox." A lockbox is a file or 
peripherals. Specifically, unauthorized CPU access to "up file segment that contains a randomly generated block- 
line" peripherals or files can result in retaliatory loss of 55 encryption key that was used to encrypt a larger data file, 
rights to "down line" peripherals, the sounding of an alarm The lockbox is created by encrypting the block-encryption 
at the computer site or to a network supervisor, or a forced key with the private key of a key pair, in this case, SG.1B. 
shutdown of the host computer which can easily be achieved To retrieve the information stored on the token, the security 
by contesting the CPU's control of the address bus and gateway would (1) open the lockbox with SG.1R and 
control signals, rendering them inoperative. In this manner, 60 retrieve the block encryption key and (2) use the block 
the security gateway is able to monitor and control User's encryption key to retrieve all the additional information 
access to all peripheral devices. Even a very skilled com- stored in the user files, such as U.XR, the user's PIN, a 
puter programmer could not program the CPU to get around Digital Certificate, security rights information, history of 
the independently enforced security parameters that are use, et cetera. The accuracy of the stored information may 
enforced at the level of the security gateway. 65 also be verified by the use of hashing techniques to produce 
As described above, this invention makes it easy to create a message digest that is stored on the token with the other 
tokens at a cost as little as the price of a single diskette. corresponding files. 
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Finally, it should be noted that for backup purposes the 
security gateway can use SG.OR to encrypt restricted 
memory in reserved sections of a hard drive and transfer 
these encrypted files to backup media. If the security con- 
troller has direct access to the backup media, these files 5 
could also be completely concealed from the CPU and all 
users. 

Having identified these steps that are most basic to all 
embodiments of this invention, it would now be instructive 
to examine a simple application of this invention. For this 10 
example, consider the case of a simple home environment. 
The parents have purchased a new computer wish, in 
general, to allow their children complete access to every- 
thing on the computer system. However, they would like to 
reserve a portion of the hard drive, or a separate logical is 
drive, that will contain certain business programs and related 
files. They hope to protect these business files from acci- 
dental corruption, computer viruses that may be transmitted 
through borrowed software or "surfing the net" or from 
teenage snooping. In this simple case, it would be sufficient 20 
to have only a single user token that is in the custody of the 
parents. This may in fact be the factory issued MASTER 
TOKEN. On first use of this token, U.O is generated and the 
parents select a PIN number to secure the token. To protect 
their business records, the parents use MASTER TOKEN to 25 
instruct the security gateway to only allow the holder of the 
MASTER TOKEN access to, for example, logical drive H 
that they are reserving for their business applications and 
business data. Non-token users would not even be allowed 
to see that drive H and its files exist, much less to access or 30 
alter them deliberately or by accident. Additionally, the 
parents wisely configure the security gateway to treat key 
programs and data files, such as those used in the operating 
system, as read-only. Non-token users, and any programs 
activated by non-token users, would not be allowed to alter 35 
or change any of these files. If desired, these files could also 
be hidden from directory reports to non-token users. The 
parent's children in this example, would be free to boot up 
the computer at any time and to do anything that is not 
restricted to non -token users. They could run programs, save 40 
files, and erase files on logical drive C, for example, but all 
of the business programs, business data, and protected 
program files would be completely protected from acciden- 
tal or deliberate corruption by either computer viruses or 
children's accidents. In this very simplest of examples, the 45 
GATEWAY PROGRAM would do little more than enforce 
a table of restricted sectors on the hard drive. The children 
might not even be aware that the security gateway was in 
existence or functional. The only imposition on the users is 
that the parents would be required to insert the MASTER 50 
TOKEN in the disk drive and enter their PIN in order to gain 
access to their business applications. As will be described 
below, much more elaborate security hierarchies can be 
developed with little more imposition on users. 
Upgrading the Security Shell 55 

The security gateway can also be used to assure the 
integrity of security programs that are operating at the CPU 
or network level. In this respect, the security gateway is 
open, under carefully controlled circumstances, to customi- 
zation. The following is a description of a typical example 60 
of the interactions between the security gateway and a CPU 
SECURITY PROGRAM, 

In this typical example, upon the powering up of the 
computer system the security gateway would reads its own 
factory installed GATEWAY PROGRAM from nonvolatile 65 
memory. It might also check for extensions to its GATE- 
WAY PROGRAM on, for example, sectors -1 through -5 of 
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the hard drive. It may then check to see if there is a system 
security shell program (hereinafter SHELL) which has been 
installed, for example, in sectors -11 to -20, The SHELL 
itself may consist of two parts: all or portions of a security 
program that is to be implemented by the CPU (hereinafter 
the CPU SECURITY PROGRAM) and further extensions 
on the security gateway's own program that are provided by 
the CPU SECURITY PROGRAM vendor to establish addi- 
tional security rules governing the interaction between the 
CPU SECURITY PROGRAM and the security gateway. 

If a CPU SECURITY PROGRAM is in place, the security 
gateway could be configured to ensure that the CPU SECU- 
RITY PROGRAM is installed at the appropriate point in 
boot up process of the system. The SHELL could be a 
factory installed, or installed by the user. Let us assume that 
there is at least a rudimentary SHELL that is factory 
installed and is capable of running a simple configuration 
setup like that used for BIOS configurations, if only for the 
purpose of facilitating the installation of a vendor supplied 
SHELL. 

The following describes one of many ways in which the 
security gateway could be used to install or upgrade the 
SHELL. To install a new security SHELL, the system must 
first be powered down. To ensure that the RAM is com- 
pletely discharged, a long powerdown may be required. This 
long powerdown requirement may be ensured by using a 
port on the security gateway controller that can detect the 
state of a slow charge capacitor circuit to ensure that the 
system has been powerdown for a long enough period to be 
adequately discharged. This is done to ensure that all RAM 
has been cleared so no virus or "monitoring" virus can be 
lurking in the background. Alternatively, the security con- 
troller can pass an initialization program to the CPU that 
would instruct the CPU to clear all RAM addresses, or in 
some configurations the security controller may be config- 
ured to directly write to RAM itself. While the system is 
powered down, the MASTER TOKEN would be loaded into 
the token reader. Upon power up, the security gateway 
would load it's own GATEWAY PROGRAM and 
extensions, if any, and immediately check to see if the 
MASTER TOKEN was in the token reader. If the MASTER 
TOKEN was detected and authenticated, the security gate- 
way defers or aborts all other initialization procedures and 
prepares to run the GATEWAY PROGRAM upgrade sub- 
routine. After confirming the user PIN associated with the 
MASTER TOKEN, the security gateway would allow a 
vendor supplied SHELL to be loaded into the secure area 
(sectors -10 to -20, in our example) from the designated 
input source. Alterations of the SHELL could be further 
restricted by requiring additional passwords or vendor sup- 
plied tokens and certificates of authority. Failed attempts to 
enter the proper tokens or passwords could be monitored to 
limit the number of attempts, provide delays between 
attempts, and reported to report attempted security breeches. 
It would be possible, and perhaps preferable, for the manu- 
facturer of the security gateway to publish interface stan- 
dards for the GATEWAY PROGRAM for developers of 
security SHELLS. This would invite competition and cre- 
ativity in the development of ever better and less obtrusive 
security SHELLS. Software developers would, however, be 
unable to sell their new SHELLS to the public until their 
programs had been accepted by the manufacturer and a 
license fee collected. At that point the manufacturer would 
issue the new SHELL a Digital Certificate and use SG.OR to 
encrypt a software upgrade token. Without this SG.OR 
software upgrade token, security gateway's would block any 
attempts to delete or alter the existing SHELL. In essence, 
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then, the communications protocol between the CPU SECU- 
RITY PROGRAM in a SHELL and the GATEWAY PRO- 
GRAM can essentially be public knowledge. Security is 
maintained by the manufacture's control of the SG.OR. Prior 
to approval of a new SHELL and licensing, the manufacturer 5 
could provide developers with a unsecured non-consumer 
version of the security gateway that would freely accept any 
software changes for the purpose of testing and evaluation. 

When a SHELL upgrade has taken place, the security 
gateway can be reprogrammed to accept future upgrades 
only after the use of an additional upgrade token from the 
software vendor that has provided the present SHELL. It 
would even be possible, with the agreement of the software 
developers and the security gateway manufacturer, to trans- 
fer future authorizations to the software developer or another 
third party. 15 
Changing Security Parameters 

Assume that by using the MASTER TOKEN to enter the 
GATEWAY PROGRAM upgrade subroutine as described 
above, the authorized user would be presented with three 
menu options: UPGRADE, TABLE MODIFICATION, and 20 
NORMAL OPERATION. The UPGRADE option would be 
selected to install new extensions to the GATEWAY PRO- 
GRAM or to install or upgrade a CPU SECURITY PRO- , 
GRAM or SHELL. By selecting TABLE MODIFICATION 
menu, the user could change passwords, redefine restrictions 25 
on directories and files for particular users or user groups, 
and define other security programs that would be allowed to 
alter the basic SHELL. These security parameters might 
include both those enforced by the security gateway and all 
or part of those enforced by the CPU SECURITY PRO- 30 
GRAM. By selecting the NORMAL OPERATION menu 
option, the user would exit the security upgrade subroutine 
and the computer initialization would resume as normal with 
both the GATEWAY PROGRAM and SHELL, if any, in 
operation. Under normal operation the CPU SECURITY 35 
PROGRAM would be allowed to read its own restricted 
access tables (which might lie in sector -12, for example) 
but it would not be allowed to alter them. Additional tables 
that must be more dynamically accessible to the CPU 
SECURITY PROGRAM for update and alteration could be 40 
stored in other areas of the hard drive and would be 
protected by methods described elsewhere. 
Additional Security Enhancements Made Possible by the 
Interaction of the Security Gateway and a CPU Based 
Security Program 45 

Essentially, what this method does is to create a peer to 
peer relationship between the CPU and the security gateway. 
The CPU cannot demand information, but can only request 
what the security gateway allows. In addition, because the 
security gateway's program and security parameters can be 50 
modified under carefully controlled conditions, the security 
software developers will continue to develop new and 
customized ways of meeting the security needs of individu- 
als and corporations. Indeed, the security gateway can be 
programmed to act as an independent "watchdog" over the 55 
CPU SECURITY PROGRAM. In other words, read and 
write access to the hard drive can be allowed only when the 
security gateway has verified that the memory resident CPU 
SECURITY PROGRAM is active and intact. Whenever the 
CPU SECURITY PROGRAM, which would include many 60 
security features itself, is not running or is under threat of 
being corrupted, the security gateway's GATEWAY PRO- 
GRAM would independently restrict access to peripherals or 
force a computer shutdown or reboot to restore the CPU 
SECURITY PROGRAM. 65 

Additional peer to peer interactions can be developed to 
enhance the system's security. For example, the security 
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SHELL, which consists of a CPU SECURITY PROGRAM 
and extensions to the security gateway GATEWAY PRO- 
GRAM could involve an elaborate scheme of checks and 
double checks that serve to constantly check and verify the 
security system's integrity. 

For example, when the security SHELL is first installed, 
a checksum of the CPU SECURITY PROGRAM could be 
stored in the security gateway's independent non-volatile 
memory. Thereafter, whenever the computer was booted up, 
the Security gateway would check the CPU SECURITY 
PROGRAM'S checksum and compare it to the stored value 
before allowing it, or any other programs in the startup 
menu, to be installed. Furthermore, when the CPU SECU- 
RITY PROGRAM is first installed at SETUP, the Security 
gateway could generate a random number (seed number 
from date, time, and available hard drive space) which could 
then be stored as the one and only SYSTEM ACCESS 
number. This number would stored in the security gateway's 
nonvolatile memory or restricted portion of the hard drive. 
Only factory test equipment could clear this number. This 
SYSTEM ACCESS number would then passed out to the 
CPU SECURITY PROGRAM, which would alter itself to 
incorporate this number at one or more places in the body of 
the key files of the CPU SECURITY PROGRAM. A new 
unique checksum would then be calculated for the altered 
CPU SECURITY. PROGRAM and stored in security gate- 
way non-volatile memory. At this point the installation 
procedure would then be complete and the CPU SECURITY 
PROGRAM would be uniquely identified and "married" to 
the Security gateway. Thereafter, whenever a reboot 
occurred, the security gateway would calculate the check- 
sum of the CPU SECURITY PROGRAM as it is read from 
the hard drive and verify it against the pre -stored value to 
confirm the integrity of the program before allowing the 
system to continue with its normal operation. 

As an additional layer of security, prior to allowing any 
writes, the security gateway could require that the CPU 
SECURITY PROGRAM provide it with both the SYSTEM 
ACCESS password and PSEUDO-RANDOM PASSWORD 
which is regenerated at each request. This PSEUDO- 
RANDOM PASSWORD would be identically calculated by 
both the Security gateway and CPU SECURITY PRO- 
GRAM (sharing the same algorithm which can be made 
unique to the system by using the SYSTEM ACCESS 
password as part of the calculation). The SEED at which 
each of the PSEUDO-RANDOM PASSWORD generators 
would begin their calculations would be generated by the 
security gateway and passed out to the CPU SECURITY 
PROGRAM periodically, or on each reboot of the system. 
These internally generated passwords would serve two func- 
tions. First, they would ensure that any program seeking 
access to the hard drive was passing these requests through 
the CPU SECURITY PROGRAM which is where the pass- 
words are added to the command strings. Second, the use of 
an ever changing password sequence would make it more 
difficult for a "spy" virus to intercept the passwords. If the 
algorithm is made unique for each system, it would be even 
more difficult for the "spy" to attempt to break the algorithm. 

Finally, the security gateway can be a "watchdog" over 
the passwords themselves. In this scheme the CPU SECU- 
RITY PROGRAM would store the passwords, and a critical 
portion of its own code, in RAM addresses that are moni- 
tored by the Security gateway. To ensure that only the 
working CPU SECURITY PROGRAM is accessing these 
passwords, the security gateway would monitor the CPU's 
RAM accesses to ensure that critical sections of the CPU 
SECURITY PROGRAM are run in proper sequence prior to 
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the password access. The location of the CPU SECURITY 
PROGRAM in RAM would be pre-defined, or would be 
passed out to the Security gateway during the initialization 
of the SHELL and stored in security gateway secured 
memory location. Through this method, the security gate- 5 
way would always know what memory locations should be 
watched before the passwords are even accessed. If another 
program attempted to read these sections of RAM tagged as 
critical to security, the security gateway could then flag the 
intrusion, sound an alarm, or even disable further access to 10 
the drive. This same technique can be used to monitor the 
bootup process. In this latter case, the security gateway 
would store in a secured memory location a record of the 
sequence of events which must occur on the BUS during a 
valid bootup. Any variation from this predefined sequence 15 
would generate an appropriate security violation alarm. 

Still another level of security can be attained by providing 
for the CPU SECURITY PROGRAM to optionally transmit 
a special command to the Security gateway which essen- 
tially says, "I'm suspicious. I think my process have been or 20 
are about to be corrupted. Force a shut down until the next 
reboot." After receiving this command, the Security gateway 
would irrevocably lock out the hard drive, sound the alarm, 
and respond only to an U.O token. For diagnostic purposes, 
the security gateway would save information about these 25 
and subsequent security breeches a secured memory location 
that can be read or cleared only with the validated U.O token. 

These examples demonstrate how the use of two inde- 
pendent processors, the CPU and the security gateway, 
simultaneously running their own independent security 30 
programs, can be utilized to substantially enhance computer 
security. Additional permutations and techniques can easily 
be devised with various levels of complexity and would fall 
within the scope of this invention. 

Token Access at Multiple Sites in a Network 35 

In many applications, it may be desirable to have a single 
token work at multiple computer stations. In this context, the 
token may be likened to a key chain, containing the keys to 
multiple computers. This end can be achieved in one of 
several ways. 40 

First, the user can be registered at each individual work- 
station with each security controller generating a different 
U.XR key secured to be readable only by each security 
controllers own SG.XR key. The user could elect to use the 
same PIN at each site. If the token is a diskette, there would 45 
be sufficient memory space to stork a large number of keys. 
Second, if the workstations are networked together the 
public keys of each security gateway, SG.XB, can be 
securely transmitted to all of the other security gateways. At * 
the time the token is created, the supervisor issuing the token 50 
could designate which terminals the user would have access 
to and the security gateway at the issuing computer would 
use the published SG.XB keys of the designated computers 
to create separate key files encrypted using each designated 
computer's SG.XB with each file containing U.XR, the PIN, 55 
and any other necessary information. The user's file for each 
designated computer could be stored under a file name using 
a portion of designated sites security gateway's public key, 
or some other site identifying tag, thus making it easy for the 
security gateway to identify the appropriate file. The user 60 
could then use the token at any of the designated computers. 
The security gateway at each site would merely need to 
search the token for the appropriate file that can be decoded 
with it's own SG.XR. 

Third, the method described above could be further 65 
enhanced by adding an additional encryption level using 
SG.1R. In this case, for each site where U.X shall be allowed 
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access through use of the token, U.XR is encrypted with 
SG.XB which is encrypted with SG.1R, where SG.l is the 
issuing computer. This "key ring" method provide a means 
by which the other security gateways can verify that the 
token was indeed created at an authorized site in the net- 
work. When using the token at another host computer #5, for 
example, security gateway #5 would examine the key for a 
designator identifying where the token claims to have been 
created. Security gateway #5 would then examine network 
files to find the published key SG.1B and examine the token 
for a key file authorizing it to be used at host computer #5. 
This file would be decrypted using SG.1B. If it decrypts 
properly, security gateway #5 has confirmed that this file 
was created at security gateway #1 has therefore been 
created under controlled and secure procedures. But the 
users file is further secured by use of SG.5B which security 
gateway #5 can decrypt using its own SG.5R. This last step 
releases U.XR and the PIN for use by the security gateway 
at host computer #5. 

Fourth, the security gateway at the network server can be 
used as a central clearing house for all user logon processes. 
In this case, all the security gateways would be configured 
in a manner that would allow the security gateway proces- 
sors to communicate over the network, preferably in a 
manner that is independent of the CPUs. In this scheme, 
each SG.XR would be registered with the host computer. 
This would be most securely accomplished encrypting 
SG.XR with the CS.1B and then again with SG.XB. As 
described above, the server could confirm which security 
gateway in the network that the packet came from and only 
the server security gateway could decrypt SG.XR by using 
CS.1R. With all the private keys collected at the security 
gateway of the central server, tokens could then be created 
simply by using SG.1B. A token used at host computer #5 
would be identified as created at host computer #1. The 
SG.1B encrypted file would be encrypted with SG.5R and 
sent to the central server. Since the central server security 
gateway alone has both SG.5B and SG.1R available in its 
restricted memory, it can retrieve the file that provides 
access to U.XR and the users PIN and other information. 
This file would then be encrypted with SG.5B then again 
with CS.1R. This file would then be transmitted back to 
security gateway #5 where its authenticity would be verified 
by decrypting first with CS.1B and then with SG.5R. In this 
way, security gateway #5 would be able to retrieve U.XR 
and other associated information. This process could be 
repeated every time the token is used at host computer #5. 
Alternatively, security gateway #5 could, at this point, add 
its own copy of the user files to the token by encrypting them 
with U.5B in the usual manner. In this way, the "key chain" 
would automatically have new keys added for each site 
immediately after its first use at each site. 
Other Network Applications 

In a network application this invention makes it easy and 
intuitive to establish a security hierarchy. For example, the 
highest ranking security officer on the network, the Corpo- 
rate Security Officer, might issue user tokens to each depart- 
ment head paying particular attention to segregation of files 
and memory allocations so that problems or security 
breeches that might occur in one department do not spill 
over into other departments. Each manager under the depart- 
ment heads would receive a token with rights no greater than 
the Department Head and most probably with additional 
restrictions. 

Tokens would not necessarily all be created by the Cor- 
porate Security Officer. Department Heads and their man- 
agers could also generate tokens for each user of a work- 
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station in their department. New tokens would always be 
limited in rights to within the bounds of issuing parties own 
allowed limits. For example, a receptionist in the bookkeep- 
ing department with 100 megabytes of hard drive space 
allocated for her word processing files could create a tem- 5 
porary token for a summer intern granting 20 megabytes of 
her space to the intern. 

Similarly, managers below the level of the Corporate 
Security Officer might be allowed the privilege not only of 
granting rights within the boundaries of their own limits, but 10 
also withdrawing rights. For example, if the head of 
accounting USER 1 discovered that his subordinate, USER 
6, was embezzling, USER 1 could immediately remove 
USER 6's access rights to the system. This security measure 
could be taken even if the Corporate Security Manager was 15 
unavailable. 

Typically, the MASTER KEYS for all computers in the 
network would be held in the custody of the highest ranking 
Corporate Security Officer. While department heads and 
lower security officers might be allowed to expand or restrict 20 
the rights of particular users or sites in the network, only the 
Corporate Security Officer, as holder of the MASTER 
KEYS, would be able to change, upgrade, or expand the 
security SHELL program or GATEWAY PROGRAMS used 
in the network. 25 

As will be detailed below, the MASTER KEYS held in 
the custody of the Corporate Security Officer can be gath- 
ered into a MASTER KEY TABLE to automate security 
changes, with this MASTER KEYTABLE secured by use of 
a single SYSTEM MASTER KEY. In this way, virtually any 30 
security changes in the network can be implemented 
remotely from the Corporate Security Officer's terminal or 
any other predetermined sites. To further secure the SYS- 
TEM MASTER KEY and the MASTER KEY TABLE for 
all the security gateways in the system, it would be possible 35 
and advisable to divide the SYSTEM MASTER KEY into 
several parts that would be placed in escrow with two or 
more trusted corporate officials. These escrowed keys would 
be useless until they are used in combination with each other 
so that the security gateway implementing the system wide 40 
changes can reconstruct the actual SYSTEM MASTER 
KEY and verify the PINS of each escrowed portion. For the 
sake of convenience, however, the following example will 
assume that there is a single Corporate Security Officer in 
whose custody all MASTER KEYS are intrusted. It will also 45 
be assumed below that the Corporate Security Officer will 
also initiate any security changes on the network from the 
central server for the network, thereby using the central 
server's security gateway key CS.l. In fact, any terminal 
could be used as long as it's public key was "published" to 50 
the rest of the network as a security gateway site that was 
authorized to make security changes. 

In the present example, the Corporate Security Officer 
would initialize each new security gateway and collect the 
MASTER KEY A GATEWAY PROGRAM subroutine 55 
would be run to provide any required parts of SG.l and U.0, 
as determined by the SHELL software vendor, to a network 
table containing this information for all secured computers 
in the network with said table stored in a restricted memory 
location that is accessible only by use of the SYSTEM 60 
MASTER KEY. In this example, let us assume that this 
MASTER KEY TABLE is stored on the central server and 
the SYSTEM MASTER KEY is encrypted with CS.1B 
which is why the Corporate Security Officer can only use it 
at that site. If desired, it would be possible to accessing this 65 
MASTER SECURITY TABLE using the SYSTEM MAS- 
TER KEY from a remote site using a technique similar to 
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that already described in option four of the section entitled 
"Token Access at Multiple Sites in a Network." In either 
case, the Corporate Security Officer would in this way be 
able to access a MASTER SECURITY TABLE, that is well 
protected in a secured gateway's restricted memory location, 
to automate security changes to a single site, multiple sites, 
or system wide. If for example, USER X is to be assigned 
new rights in the accounting department and have all rights 
removed in the purchasing department, the Corporate Secu- 
rity Officer could use the SYSTEM MASTER KEY to 
activate a SHELL subroutine that would identify all the 
computers that should be instructed to refuse access to 
Token U.X and also to notify all the computers that should 
now accept Token U.X. These network messages would be 
"signed and sealed" by encrypting the message first by use 
of each target computers SG.XB and secondly by use of 
CS. 1R. The security gateway receiving the message packet 
could then confirm that the message came from the central 
server, using CS.1B, which is authorized to execute security 
changes, and then to read the private message using its own 
private key, SG.XR. 

Most security changes involve either (1) expanding one or 
more rights of a user or (2) restricting one or more rights of 
a user or (3) changing or upgrading the security program 
used at a site or network wide. The last of these is always 
problematic and should always be strictly controlled. 
Changes in user or site rights, however, involve varying 
degrees of risk. When disgruntled employees or computer 
hackers restrict a users rights, this is generally very incon- 
venient but seldom provides an opportunity to cause great 
damage to corporate data. A far more serious problem is 
when a hacker manages to expand his rights so as to gain 
access to files that would normally be deprived to him which 
he can then steal, alter, or destroy. Conversely, when a 
Corporate Security Officer needs to expand the rights of an 
employee, delays in doing so can be inconvenient, but 
seldom damaging. But if the Corporate Security Officer 
needs to restrict the rights of an employee who, for example, 
is about to be fired or has made threats against the company, 
speed can be essential. This analysis suggests that network 
computer security might be enhanced by a process that 
delays and verifies the expansion of rights but never impedes 
the restriction of rights. 

The security technique described above can be easily 
implemented by use of the security gateway disclosed in this 
invention. The network SHELL would be designed to allow 
the Corporate Security Officer or any holder of a token with 
a higher security rating, a department manager for example, 
to revoke any or all rights of a particular user or network site 
either on site or from a remote location. However, to expand 
the rights of a particular user or network site, the Corporate 
Security Officer, or other to authorized parties could only 
transmit a conditional upgrade of rights. On reception of this 
message, the local security gateway and SHELL would 
notify the user that a rights upgrade has been authorized. 
This upgrade of rights, however, would not become active 
until authorized by an approved authority at that site. This 
might be a department head, for example, who has been 
issued a separate SECURITY UPGRADE token. The secu- 
rity upgrade would be accepted by the security gateway only 
after the SECURITY UPGRADE token was placed into the 
token reader and authenticated by use of the appropriate 
PIN. In this manner, it would be impossible to remotely 
grant expanded rights to a terminal or user without the 
collaboration of an on site agent. If the department head, in 
this example, had not received notice of the security 
upgrade, policy would require him to check with the Cor- 
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porate Security Officer before allowing the upgrade to be 
completed. The use of an onsite SECURITY UPGRADE 
token would be especially important if extensions or 
changes to the security SHELL are to be implemented. 
Restricted Program Lists 5 

A widely desired feature is the ability to restrict what 
programs can be run on a corporation's computer. The 
ability to restrict the use of unauthorized programs is impor- 
tant to prevent employees from introducing computer virus 
programs into the system and also to curtail the risk of costly 10 
copyright and licensing violations. Because the security 
gateway can easily be configured to restrict users activities, 
it would be a simple task to create a table of executable files 
that are allowed to be loaded onto the hard drive or other- 
wise executed by the CPU. Alternatively, a list can be made is 
to exclude the installation or operation of popular programs 
that are frequently the target of illegal copying. 

The program restriction subroutine can designed to be 
either very inflexible (absolutely no unauthorized programs) 
or safely flexible (unauthorized programs can only be run in 20 
special isolated parts of the drive, and will automatically be 
deleted on a periodic basis). On the inflexible side, autho- 
rized program names and checksums could be stored on the 
network, CPU accessible areas of the hard drive, or in 
restricted memory. User rights to these programs could be 25 
flagged and updated by the computer security ofiicer. The 
Security gateway's own security shell would assist the CPU 
security shell in enforcing these restrictions. Alternatively, if 
the user is authorized to operate on a "safely flexible" 
system, the security gateway would reserve an isolated 30 
section of the drive for any non-corporate programs the user 
might wish to examine, test, or run. Any attempt to load an 
unauthorized program onto the system would automatically 
be routed to a safe zone, for example, virtual drive S. In this 
in example, whenever a user logged onto drive S, or sought 35 
to open any files or programs there, the Security gateway 
would immediately rescind access to all other portions of the 
hard drive that are related to corporate files and could force 
the host computer to disconnect from any networks to which 
it is connected until the system is powered down or other- 40 
wise resecured. Only the sectors apportioned to user's drive 
S would be readable or writable to the CPU. In this way, the 
user could load or run any private programs, games, or even 
known computer viruses without exposing any other parts of 
the system to corruption. This method allows corporate 45 
officials the luxury of using the computer for private pur- 
poses while maintaining a secure Security gateway enforced 
wall between corporate files and personal files. 

In a similar way, new programs being developed by 
corporate programmers could be automatically restricted by 50 
the security gateway to a specific virtual drive or develop- 
ment site. This restriction could only be lifted by the 
computer security officer who has access to the MASTER 
TOKEN after the new software had been tested and 
approved for general use. This provision would severely 55 
limit a corporation's exposure to disgruntled employees who 
are skilled computer programmers. 
Internet Activities 

As more and more communications occur across 
networks, on the Internet, for example, security becomes 60 
increasingly difficult. The present invention is has numerous 
application in securing such Internet activities. For example, 
the security gateway could easily be programmed to limit 
disk and network access whenever a CPU is connected to the 
Internet. In this way, the security gateway would automati- 65 
cally quarantine and block any destructive Internet programs 
employing Java or ActiveX or similar cross platform appli- 
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cations by limiting their activities to a secured area of the 
computer system. 

Just as the security gateway can be used to enforce a table 
of authorized programs, so also could it enforce a table of 
authorized Internet sites that a user would be allowed to 
visit. By means of the security gateway, for example, even 
computer savvy children could be prevented from entering 
Internet sites with inappropriate material. Similar CPU 
based programs already exist, but can be easily defeated 
simply by installing an unrestricted web browser. 
Privacy, ID verification, and Traceability on the Internet 

The Internet provides unique opportunities and problems 
for communications and commercial transactions. There are 
conflicting interests in terms of preserving the privacy of 
Internet user, verifying the identity of users, securing the 
integrity of financial transactions, and being able to track the 
identity of parties in the event of a criminal activity. The 
following process is illustrative of many techniques that 
could be employed to take advantage of the features offered 
by the security gateway to satisfy these conflicting needs. 

The goal is to create the electronic equivalent of a "paper 
trail" of signed documents that under normal circumstances 
is concealed, ensuring privacy, but can be investigated and 
decoded with proper authorization, such as a court order or 
with permission of the transacting parties, to investigate a 
crime or verify disputed issues. Confidence in this "paper 
trail" is assured using the security gateway as an indepen- 
dent means for guaranteeing that a sending party is using a 
computer that is under the control of an authentic security 
gateway and licensed security SHELL. Because the receiver 
knows that an authentic security gateway is ensuring that the 
proper secure communications protocol is being followed, 
the receiver can know that a proper "paper trail" is being 
recorded which can be decoded in the event of fraud or 
criminal behavior. Indeed, when agreed to by the transacting 
parties, or when demanded by law, anonymous but traceable 
transactions can be easily accomplished. In the following 
discussion, this will be referred to as a CERTIFIED 
TRANSACTION. 

The key to this technique is the ability to confirm that a 
communicating computer is indeed under the supervision of 
an authentic security gateway. This can be accomplished by 
the manufacturer embedding in each device a "public key" 
that is common to all of the security gateways in that line of 
products. In this example, it will be assumed that SG.OB is 
used, although there could be a different key used for this 
specific purpose. At the start of a CERTIFIED 
TRANSACTION, the security gateway would encrypt a 
SELF-IDENTIFYING MESSAGE, including, for example, 
its own serial number, the version of the GATEWAY PRO- 
GRAM and SHELL in use, and a copy of SG.1B, using 
SG.OB. This SELF-IDENTIFYING MESSAGE is sent over 
the Internet to the manufacturer using a proprietary protocol 
for added security and verification of identity. The manu- 
facturer's host site uses SG.OR to decrypt the package, 
thereby confirming that the SELF-IDENTIFYING MES- 
SAGE must have been encrypted by an authentic security 
gateway since only security gateways manufactured by the 
company have access to the SG.OB. The authenticity of the 
security gateway can be further confirmed by including in 
the SELF-IDENTIFYING MESSAGE, other security gate- 
way embedded data, such as a serial number, and the fact 
that the proprietary communications protocol was properly 
used. 

Included in the SELF-IDENTIFYING MESSAGE would 
be information about the user as stored on the token in use. 
Most ideally, this would be in the form of a Digital Certifi- 
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cate that can be used to identify of the token holder. If the 
sender is seeking to complete an anonymous but traceable 
transaction, the manufacturer would need to verify the 
authenticity of the Digital Certificate using the published 
public key of the certifying authority that had issued the 
certificate. This step could be skipped if the receiving party 
will be provided with an unsealed Digital Certificate in 
which case the receiving party will open and verify the 
Digital Certificate. 

If the sender is seeking to send anonymous but traceable 
communication, the manufacturer would confirm the 
authenticity of the Digital Certificate and then reencrypt it 
using AK.1B, the public portion of a anonymous transaction 
key. AK.1R would be held in divided escrow form by two or 
more trusted authorities. A message packet would be 
attached to this packet confirming that the AK.1B encrypted 
Digital Certificate had been authenticated by the manufac- 
turer and could be retrieved with proper authorization, such 
as a court order, by the parties holding AK.1R in escrow. If 
desired, a date and time stamp could also be added to this 
message packet, plus information about the GATEWAY 
PROGRAM and SHELL that is "refereeing" this 
transaction, and information about the authority that had 
issued the original Digital Certificate and how that authority 
was able to confirm the identity of the sender: birth certifi- 
cate on file, photo on file, fingerprints on file, et cetera. This 
information would allow the receiver the opportunity to 
grade the quality of the Digital Certificate and to evaluate 
how much trust can be placed in the claim that the certifying 
authority has adequately verified the identity of the sender. 
This packet containing the AK.1B encrypted version of the 
original Digital Certificate and added information would 
then be encrypted again using CA.1R, the private portion of 
key pair used for certificates of authority issued by the 
manufacturer. This CA.1R packet will hereafter be referred 
to as a digital Certificate for An anonymous Party, or CAAP. 
Finally, the CAAP is encrypted with SG.1B, which was 
transmitted to the manufacturer as part of the SELF- 
IDENTIFYING MESSAGE, and transmitted back to the 
security gateway that initiated the transaction. The security 
gateway then uses SG.1R to retrieve the CAAP which can 
then be stored on the token or immediately transmitted over 
the Internet to the receiving party. Immediate transmission 
may be required in some secured transactions and could be 
verified by use of the date and time stamp information 
imbedded in the CAAP by the manufacturer. The receiver of 
the CAAP would then use publicly published CA.1B to 
confirm that the authenticity of the AK.1B encrypted iden- 
tifying Digital Certificate had been independently verified 
by the manufacturer. If the CAAP is accepted by the 
receiver, the associate transaction would completed. 

If the sender is not anonymous and is offering to allow the 
receiver to examine the token holder's Digital Certificate, 
AK.1B would not be used. The manufacturer might still 
include a date and time stamp and then reencrypt the Digital 
Certificate using CA.1R and transmit it back to the security 
gateway using SG.1B. Using SG.1R the security gateway 
would recover the Digital Certificate that now has the 
additional certification from the manufacturer that the holder 
of the certificate is using a computer that is using a security 
gateway. 

Because the manufacturer is able to confirm the use of a 
security gateway and the version of the licenses SHELL and 
GATEWAY PROGRAM in use, parties in electronic trans- 
actions of information or financial assets can be assured that 
the transaction is properly governed by whatever protocols 
are mutually agreed upon. Because the security gateway is 
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independent of the CPU, it cannot be altered or tampered 
with by computer programmers. 

The above discussion assumes that the manufacturer of 
the security gateway would provide the clearinghouse for 
verification of security gateways and issue for issuing 
CAAPs or other certificates of authority. In practice, 
however, this responsibility could be transferred to a third 
party as designated by the manufacturer and/or the owner of 
the security gateway with appropriate token authorization 
from the manufacturer. 

Finally, it should be noted once more that while the 
discussion above refers to encryption and decryption of 
messages using one or the other part of a key pair, it may be 
preferred in practice to encrypt the bulk of a message with 
another type of key, such as a block encryption key, which 
may provide speed or security enhancements. This other key 
would then be encrypted with the appropriate portion of the 
key pair to create a lockbox, as previously discussed. In this 
way, the entire message can only be decrypted with the 
appropriate key of the key pair first by opening the lockbox 
and then using the key in the lockbox to decrypt the rest of 
the message. 
Non-duplicatable Tokens 

As previously described, a simple floppy diskette can be 
used as a token. The information on the diskette is securely 
encrypted with SG.1B so that it is only readable by the 
security gateway that issued the token (except in network 
situations where, as previously described, where token shar- 
ing techniques are employed). The token is further secured 
by means of a user PIN and any other identifying informa- 
tion that may be collected and used for verification of the 
person's identity. 

Still, when using a simple floppy diskette, it would be 
possible for an exact duplicate to be made. In some cases, 
this may be advantageous if the user wanted to keep a "spare 
key" in another location. On the other hand, it also provides 
an opportunity for an intruder who gains temporary access 
to the key to undetectably make a perfect copy of the key. 
The intruder would still need to gain access to the PIN and 
other information, if any, but his job would be half done. 

There are two general ways to thwart the duplication of 
tokens. First, if security gateways are installed in all com- 
puters in system, the GATEWAY PROGRAM can recognize 
that the diskette which the user is asking to duplicate is a 
token, even if it is a token for another security gateway. The 
security gateway can be programmed by the manufacturer or 
a Corporate Security Officer either to (1) never duplicate a 
token diskette, or (2) only to duplicate a token diskette after 
confirmation of a duplication request by the token holder's 
PIN and other information and/or permission of a security 
officer or department manager using their tokens. 
Additionally, the security gateway might be programmed to 
not only refuse to make a duplicate of a TOKEN but also to 
report the attempt to copy the token to the network 
supervisor, to make a false copy that will set off an alarm 
when used, or to mark the stolen token so that the owner will 
be notified of the attempted copy attempt the next time it is 
used, or to even remove rights granted to the token holder, 
either temporarily or permanently. 

As these security gateway technology becomes more 
common, the techniques described above, and similar tech- 
niques that will be obvious to those skilled in the security 
arts, will provide an effective means the security gateway 
technology itself will be able to block the unauthorized 
duplication of tokens. 

The second alternative is to use a unique diskette format 
or media for tokens that cannot be duplicated by disk drives 
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other than those controlled by a security gateway. While SG.OR is used by the manufacturer to encrypt a Digital 

special formatting could be used, it is likely that a deter- Certificate that is provided to the licensed SSL software 

mined corporate spy could find a means to develop a device vendor for distribution with their products. Upon installation 

that could mimic the formatting method and read and write ? f tne SSL licences software, the security gateway would use 

in that format. Perhaps the most secure option would be to 5 its embedded SG.OB key to verify that the SSL license is 

create token media that is permanently marked or coded in valid and execute the appropriate subroutines required to 

a non-duplicatable manner. implement the SSL protocol for the new SSL program(s). 

There are many copy protection schemes that can be used ™?, technique of verifying an SSL licenced product is 

to make diskettes which are uncopyable or at least extremely ^^1^1 ven £|?S the right to upgrade the 

difficult to copy. One method involves laying down an 10 G^WAY PROGRAM or SHELL. 

analog track with a pattern of identifying bits (a . * xam P le f of a ° SSL J 3 ™* ' ^ 

uc ■ 4 »\ • j j j ■ .... , 4 / , 6 . , \ installation and initialization of an SSL protected program, 

fingerprint ) embedded in this track. If the drive heads ^ software wou]d be {Q ^ £ ^ Q ' 

consistently read this track the same way, then it is known the host computer . If the softwm % transferred to another 

that this track is a binary one and the diskette is rejected as comp uter, the other computer's security gateway will not 

a copy. Only if this track gives varying results, except for the is have SG.1R and will therefore be unable to decrypt the file 

embedded identifying bits, is the diskette assumed to be the an( i me pr0 gram would thereby be rendered useless on other 

original. If the identifying bits are unique for each diskette systems. 

manufactured, then each diskette is essentially unique. This A specific advantage of this technique is that backup 
identifying information can be read by the security gateway copies of the software can easily be made, but they will only 
and can be stored in the SG.1B encrypted files along with 20 be useful when reloaded onto a computer in which the 
U.XR. Thereafter, whenever a token diskette is inserted into security gateway to which it was "married" is still active, 
the drive, the security gateway would check the diskette's This would be especially useful with tape drive backups of 
actual "fingerprint" and compares it to the copy of the an entire hard drive. If there was a hard drive failure but the 
fingerprint encrypted in the security file. If the diskette is a security gateway was intact, a new hard drive could be 
copy, the fingerprints will not match and the token would be 25 installed and all files restored and the SSL protected pro- 
rejected or the user could be channeled into a network grams would immediately work without the requirement for 
security trap. It should be noted that standard copy protected new "marriage." 

diskette scheme described above proved vulnerable to hack- Protocols can also be developed to "divorce" software 

ers disassembling the CPU code and disabling the subrou- from a particular site so that it can be "remarried" to a 

tine that went out to check for the analog track. In this 30 different host computer. Similarly, a protocol can be imple- 

application, however, because this code would be part of the mented to transfer the software to another computer in the 

GATEWAY PROGRAM stored in restricted memory, it event the host computer or security gateway to which the 

would not be vulnerable to disassembling or alteration. software was "married" is destroyed or rendered inoperable. 

Other mechanical or chemical marking techniques might The following is illustrative of how the security gateway can 

also be employed to create special diskettes that can be used 35 be used in this fashion. Additional variations will be obvious 

as tokens wherein each token would have a unique "finger- to those skilled in the art. 

print." The diskette media might be precisely or randomly Marriage Procedures 

scarred with lasers, chemical spattering, ion bombardment, In this example of an SSL Protocol, the security gateway 

or other means. It would be sufficient to simply have a would examine a files prior to allowing CPU access to 

number of sites that either no magnetic charge or a fixed 40 determine if the file has an internal tag identifying it as an 

magnetic charge. When creating a new token, the security SSL protected file. An SSL file can also be marked with a file 

gateway could consecutively write and read all O's and all code which tells the Security gateway that said file is 

l's to the diskette and identify the unreadable or unchange- available for use by the security gateway only and cannot be 

able bits which could then be used to describe the diskette's shared with the CPU nor can it be copied without alteration 

"fingerprint" pattern. As described above, a description of 45 to another file or media. This tag can be likened to a "DO 

this fingerprint pattern can be encrypted with U.XR so that NOT SHARE" tag that would attached to the SSL certificate 

any other diskette containing the which did not match the of authenticity. 

fingerprint pattern would be rejected as a valid token. SSL licensed software would come with a token contain- 

Single Site Licensing of Software ing a Digital Certificate identifying it as an SSL protected 

Software developers and those who sell electronic infor- 50 product. In this example, the Digital Certificate, hereinafter 

mation are constantly seeking for a better way to protect referred to as the SSL Certificate, would be initially have 

their products from being copied and distributed to other been encrypted with SG.OR. 

computers. Using the security subsystem's CONTROLLER The SSL certificate would include a complete "marriage" 

and its own public/private keys, as previously described, it record for this specific copy of the software. The software 

is possible to automate SINGLE SITE LICENSING (SSL) 55 could not be run until it was first "married" to the security 

of software or data. In brief, software can be sold which gateway installed in the host computer on which it is to be 

would only operate on computers which have the SINGLE run. At the first initialization of the software, the security 

SITE LICENSING (SSL) protocol installed and operated by gateway reads the SSL certificate using SG.OB to verify that 

the security gateway. The requirement for use of an SSL the software is not presently "married" to another device. If 

enabled security gateway would be enforced by the use of 60 the software is "unmarried" the security gateway modifies 

licensed encryption key pairs issued by the manufacturer of the SSL certificate to record its marriage including in the 

the security gateway. certificate any user ID information which may be provided 

The security gateway is configured to recognize SSL for by the SSL Protocol for tracking down software theft as 

licensed software by means of key pair that is provided in a provided hereafter. The SSL certificate, or portions thereof, 

restricted memory location either at the time of manufacture 65 is thereupon encrypted with the Security gateway's public 

or during the upgrade or installation of a new GATEWAY key, SG.1B, so that it can thereafter by decrypted only by the 

PROGRAM. For this example, it can be assumed that the security gateway to which it has been married. 
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The SSL certificate may also contain the software ven- 
dor's public key which can be used by the Security gateway 
to decrypt essential sections of the file. At this point the 
software vendor may have the option of designating that 
these sections of the code, as identified in the SSL certificate, 5 
shall be reencrypted with the security gateway's public key, 
SG.B, during installation. Subsequently, only the Security 
gateway which is "married" to that copy of the software 
could decrypt these critical sections of code and pass them 
on to the CPU. 10 

After the above initialization procedures, whenever the 
CPU attempts to access an SSL protected file, the Security 
gateway first reads the embedded SSL certificate to deter- 
mine if the software is "married" to said security gateway. It 
not, it then determines if the software is "married" to another 15 
Security gateway and the "adulterous" CPU's is denied 
access to the requested files. If the certificate shows that the 
software is indeed "married" to said security gateway the 
Security gateway then checks its own DIVORCE FILES, 
which are located in restricted memory, to determine if the 20 
software has previously been "divorced" from the Security 
gateway, or, in other words, uninstalled so that it could be 
transferred to another computer site. If there is a history of 
divorce indicated, the files will not be read. In short, the CPU 
is allowed to read the SSL protected files only after their 25 
"marriage" to the Security gateway has been authenticated. 
Divorce and Remarriage Procedures 

At the vendor's option, a "divorce and remarriage" pro- 
tocols could provide a means for uninstalling the SSL 
protected program from its original site so that it can be 30 
transferred to another computer with an SSL enabled secu- 
rity gateway. Using key pairs provided by the SSL protocol, 
the "divorcing" security gateway and "new spouse" gateway 
could communicate over a network or by the exchange of a 
token to confirm and verify that each party is an SSL enabled 35 
security gateway and to exchange their respective public 
passwords, SG.1B and SG.5B, for example. Upon obtaining 
SG.5B, the security gateway that was presently "married" to 
the software would use SG.5B to reencrypt the SSL 
certificate, including in the certificate a record of the prior 40 
"marriage" to SG.l and transfer of the marriage to SG.5. 
Any SG.1B encrypted blocks in the software would also be 
reencrypted using SG.5B to enable the transfer or "remar- 
riage." 

The "divorcing" security gateway would also place a 45 
record of the divorce into a table in its own restricted 
memory. This is done to prevent an attempt to reload a 
backup copy of the "divorced" software onto the system. If 
this is attempted, the security gateway would recognize from 
the table that while it is able to read this copy of the software, 50 
it is not authorized to do so because of the divorce. 

Similarly, it is now a common practice for trial copies of 
software to be available through the Internet. If a trial copy 
was SSL enabled, after the trial period was over the security 
controller would make a record in its restricted memory 55 
noting that this software has been tried for the allotted 
number of times or period of time. Subsequent attempts to 
uninstall the trial software and to reinstall it for a second trial 
period would be refused by the security gateway. 
Death Certificate 60 

In the unlikely event that the security gateway itself was 
damaged or destroyed, users might be allowed to return the 
token containing the SSL certificate to the vendor for 
issuance of a "virgin" copy. The Protocol, however, would 
provide that the returned token would contain a file created 65 
by the first security gateway which would include the user's 
registration information and the "dead" security gateway's 
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public key, SG.1B. This public key would then be posted on 
an Internet morgue file. Purchases, registrations, and other 
transactions which require submission of , the security gate- 
way public key could then be checked against the morgue 
file. Any transactions by a security gateway previously 
reported as "dead" by a user could trigger withdrawal of 
privileges, investigation of fraud, and civil or criminal 
sanctions. 

Electronic Purchases 

The above procedures assume that SSL software is pur- 
chased on removable media, in which case the SSL certifi- 
cate is already in place. When the software or data is 
transferred electronically, the SSL protocol can easily pro- 
vide for the host security gateway to create an SSL certificate 
which would serve to control the marriage and divorce 
procedures as outlined above. 

It is also noteworthy that in electronic transfers of 
software, the software or data vendor could request SG.1B, 
or a similar public key owned by the security gateway that 
is to be used for SSL transfers. Using this key, SG.1B, the 
vendor could then provide the files with the SSL certificate 
and any other encrypted blocks already encrypted with the 
SG.1B, In other words, if provided with the security gate- 
way's public key in advance, the software vendor could 
complete the "marriage" even before the software is deliv- 
ered to the buyer. This would be the most effective means for 
preventing unauthorized use of commercial software or data 
files. 

Secure Cycling to New Keys 

With sufficient computing power, it is possible to factor or 
"crack" a private key. Yet even if the network manager of a 
large corporation were to harness the parallel processing 
power of thousands of computers, the factoring of even a 
small key would take many months or even years. This 
lengthy period of time required to "crack" a key, even when 
one has immense computer resources, provides a safe zone 
during which a key pair can be considered safe. After a year 
or so, however, one must consider the possibility that critical 
key pairs, such as SG.O and U.OR could be compromised. 

However, since each security gateway is capable of 
generating its own SG.l key pair, there is no reason it could 
not generate a new key pair every six -months, for example. 
If this were done, the complete history of previous keys 
would stored in a restricted area and/or backed-up using the 
latest SG.1B. Drawing on this historical record, security 
gateway could always decrypt files that had not previously 
been updated with the new SG.1B. In this way, previously 
encrypted files that were opened would automatically be 
re-keyed. Similarly, tokens U.O, U.l, and U.X, could also be 
automatically updated with the newest SG.1B and be issued 
new U.XR keys, at periodic intervals. A historical record of 
U.XR keys would be kept on the token in a file encrypted 
with the most recent SG.1B. Such periodic replacement of 
"old" keys with fresh ones can be done automatically by the 
CONTROLLER with out any involvement of the user. The 
user need not even be aware that it is taking place. The only 
cost would be a slight delay when the user accesses a 
secured file which is overdue for being be re-keyed. 
Ramifications, Scope of Invention and Conclusion 

The present invention increases the security options avail- 
able to computer users by introducing a new level of control 
over the computer's access to its peripheral devices. In the 
prior art, computers have had a direct and unlimited control 
over their peripheral devices. The users control over the 
peripherals is implemented through a programs operating at 
the CPU level. But since a computer's CPU can come under 
the control of a malicious person or a computer virus, this 
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unlimited access to the peripheral device places the autho- 
rized user's data and programs at risk of alteration or 
deletion. 

The present invention overcomes this inherent weakness 
in the prior art by implementing another level of user control 
over the computer. This control occurs directly at the mid- 
point between the computer's CPU which operates 
programs, and the peripheral devices which are directed by 
the CPU to implement programs or retrieve and store data. 
Because the security gateway is independent of the CPU, 
this invention makes it impossible for any program run by 
the user to cross over into restricted memory areas to read, 
alter, or erase data. Thus, even a system programmer with 
extensive rights cannot bypass or alter the Security gate- 
way's security program. Furthermore, as described in the 
previous disclosure, the Security gateway can protect the 
CPU's boot tracks, security shell, and even RAM tables 
reserved for the security shell. 

While this invention provides an unbreechable barrier 
against security attacks initiated at the CPU level, it also 
retains flexibility, providing a means for security software 
designers to enhance and customize security SHELL to meet 
evolving consumer needs. 

The method disclosed in this invention produces the 
following advantages: 

it allows the user to temporarily make all or portions of a 
peripheral device completely inaccessible to the com- 
puter; 

it allows the user to temporarily make all or portions of a 
peripheral device read-only; 

it allow the user to temporarily make all or portions of a 
peripheral device write-once so that important data may 
not be accidentally erased or written over; 

it allows the user to temporarily make all or portions of a 
peripheral device write-only so that sensitive data may not 
be read or copied except under authorized conditions. 

it provides means for alerting the user of unauthorized 
attempts by the computer to access a secured peripheral 
device which may aid in the detection and elimination of 
computer viruses or other interlopers. 

it provides a means for anonymous but traceable electronic 
transactions that offer both parties the assurance of trace- 
ability and the confidence that the their identities are 
protected unless there is a authorized investigation, such 
as by court order. 

it provides a means for single site licensing of software to 
prevent the unauthorized use or duplication of intellectual 
property. 

Although the description above contains many specifica- 
tions and precise examples, these should not be construed as 
limiting the scope of the invention but merely provide 
illustrations of some of the principle ways in which the 
invention can be implemented. Once disclosed, customizing 
of this process to suit an individual client's security needs 
will be obvious to one skilled in the art. 

Thus, the foregoing is considered as illustrative of the 
principles of the invention, but is not by any means exhaus- 
tive. Numerous modifications and changes will be obvious 
to those skilled in the art. Therefore, it is not desired to limit 
the invention to the exact construction and process shown 
and described herein, and accordingly, all modifications and 
equivalents which utilize a user accessible switch which 
limits a computer's access to its peripheral devices fall 
within the scope of this invention. 

While preferred embodiments of the invention have been 
disclosed in detail, it should be understood by those skilled 
in the art that various other modifications may be made to 
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the illustrated embodiments without departing from the 
scope of the invention as described in the specification and 
defined in the appended claims. 
What I claim is: 

1. A method for providing security for a computer com- 
prised of a central processing unit, peripheral and file storage 
devices, at least one of which can be used as a token access 
device that can read and write files to removable storage 
media suitable for use as a token, a computer operating 
system, and a CPU independent security subsystem which 
includes a security control unit and programmable auxiliary 
memory, sad method comprising of the steps of: 

(a) generating with said security control unit a security 
subsystem key pair comprised of a public key and a 
private key; 

(b) storing said private key data in a memory location 
which is under the control of the said security sub- 
system; 

(c) creating with said security -subsystem a key file 
encrypted with said public key and writing the key file 
to a master token by means of said token access device, 
such that said encrypted key file can only be decrypted 
and authenticated by the security subsystem using its 
corresponding private key; 

(d) allowing access to said security subsystem after initial 
installation and setup by said computer operating sys- 
tem for installation and modification of security 
requirements only when said master token is placed 
into an appropriate file storage device and said 
encrypted key file has been authenticated by the secu- 
rity subsystem; 

(e) denying file and peripheral device access requests by 
the central processing unit when the security require- 
ments are not satisfied. 

2. The method of claim 1 further including the steps of: 

(f) creating with said security subsystem a special use 
token containing a special use file encrypted with said 
public key such that said special use file can only be 
decrypted and authenticated by the security subsystem 
using its corresponding private key and such that said 
special use file contains information that identifies 
specific access rights and security restrictions that are 
applicable to the user of said special use token; 

(g) providing to said security subsystem by a given user 
a valid user identification immediately after said special 
use token has been authenticated by the security 
subsystem, indicating to the computer operating system 
only those files which are accessible to the given user 
of said special use token and whether read operations, 
write operations, and execute operations may be per- 
formed upon the accessible files, and denying access to 
users with invalid access criteria and refusing to write 
data to any of the files stored in the file storage devices 
when operations without valid access criteria have been 
attempted. 

3. The method of claim 2 further including the steps of: 

(h) generating with said security control unit a user 
specific key pair comprised of a user public key and a 
user private key which can be used for authentication, 
verification, and private communications by a given 
user; 

(i) writing to said special use file a copy of said user 
private key which has been encrypted with the security 
subsystem's own public key; and 

(j) storing said user public key in at least on file stored on 
at least one other file storage devices. 
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4. The method of claim 2 further including the step of: 
(h) requiring the security subsystem to access a central file 

which contains the public keys for the security sub- 
systems of other computers and to make encrypted 
copies of the special use file using the public keys of the 
other security subsystems to which the user has been 
granted limited access and to store these encrypted files 
on the special use token, whereupon the special use 
token can be securely used on the other computers. 

5. The method of claim 2 further including the steps of: 

(h) connecting the computer to a computer network; and 

(i) providing that the security subsystem's parameters can 
be changed by the network manager at a remote loca- 
tion only when a special use token with security 
authorization to allow this change has been placed into 
the local token access device and authenticated by the 
security subsystem, 

6. The method of claim 2 further including the step of: 
(h) requiring the security subsystem to record invalid 

attempts to enter user identification information on the 
token and to initiate additional security precautions if 
the number of invalid attempts exceeds a predefined 
limit. 

7. The method of claim 1 further including the step of: 
(f) requiring the removable media to be of a type which 

has fixed or unwritable domains by which the security 
subsystem can uniquely identify the diskette and record 
the identifying diskette information in the key file 
recorded on the diskette such that if the key file is 
copied to another diskette the security subsystem can 
determine that the key file does not reside on the same 
removable token on which it was originally placed and 
so can reject the non-original diskette as a copy. 

8. A computer security system for a computer having a 
CPU, a common bus carrying control logic signals, address 
signals, and data signals, and a computer operating system 
which comprises: 

(a) means for providing a CPU independent security 
subsystem comprised of a control unit, programmable 
memory, a security program and general security 
parameters; 

(b) means for attaching said security subsystem and a 
plurality of peripheral devices and file storage devices, 
with at least one of said file storage devices capable of 
reading and writing to removable media which will be 
used as a token read/write device, to said common bus; 

(c) means for said security subsystem to generate at least 
one pair of keys comprising a private key and a public 
key and storing sad pair of keys in a restricted memory 
location residing on at least one of said file storage 
devices under the control of said security subsystem; 

(d) means for said security subsystem to encrypt at least 
one key file using said public key and to write said 
encrypted key file by means of said token read/write 
device to a token comprised of removable storage 
media; 

(e) means for requiring said security subsystem to deny 
access requests by said CPU to said peripheral and 
storage devices whenever said access requests violate 
said general security parameters; and 

(f) means for requiring said security subsystem to accept 
modifications of said general security parameters after 
initial installation and setup when said token is inserted 
into said token read/write device and said security 
subsystem has decrypted said encrypted key file using 
said private key and thereby verified the authenticity of 
said token. 
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9. The computer security system of claim 8 further 
including 

(g) means of storing a copy of said security subsystems 
manufacturer's public key in a secure memory location 
of said security subsystem; and 

(h) means for requiring said security subsystem to accept 
modifications of said security program when a master 
token containing an upgrade authorization file 
encrypted by said manufacturer's private key is 
inserted into said token read/write device and said 
security subsystem has decrypted said encrypted key 
file using said manufacturer's public key and thereby 
verified the authenticity of said upgrade authorization 
file. 

10. The computer security system of claim 8 further 
including: 

(g) means for said security subsystem to generate a 
special use key pair comprised of a special use public 
key and special use private key and to store said special 
use public key on at least one of said file storage 
devices; 

(h) means for said security subsystem to create a special 
use security parameters file encrypted with said public 
key that contains at least a copy of said special use 
private key and to write by means of said token 
read/write device said special use security parameters 
file to a special use token; and 

(i) means for said security subsystem to retrieve said 
special use security parameters file from said special 
use token when said special use token is inserted into 
said token read/write device and to limit access 
requests by said computer to said peripheral and stor- 
age devices for a period of time and under such 
conditions as provided by said security program and 
said special use security parameters. 

11. The computer security system of claim 10 further 
including: 

(k) means for obtaining a PIN assigned to a user autho- 
rized to use said special use token and storing said PIN 
in a PIN-file encrypted with said public key and storing 
said PIN-file on said special use token; 

(1) means for said security subsystem to retrieve said 
PIN-file from said special use token when it is inserted 
into said token read/write device and retrieve a key- 
board entry of the PIN as a means of verification of said 
specific users identity; and 

(m) means for said security subsystem to utilize said 
special use security parameters only when said PIN 
matches the keyboard entered value and to otherwise 
utilize said general security parameters. 

12. The computer security system of claim 8 further 
including: 

(g) means for said security subsystem to monitor the 
integrity of a CPU security program and to force a 
computer reboot operation whenever said integrity 
check fails to satisfy said general security parameters. 

13. The computer security system of claim 8 further 
including: 

(g) means for said security subsystem to generate a seed 
number that is stored in a memory location accessible 
to a CPU security program run by said CPU and said 
operating system; 

(h) means for said security subsystem and said CPU 
security program to use said seed number in identical 
random number generating routines to create a pseudo- 
random password; and 
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(i) means for said security subsystem to require said CPU 
security program to supply said pseudo-random pass- 
word at such time and under such conditions as 
required by said general security parameters and to 
activate security breech operations as defined for this 5 
case in said general security parameters when ever said 
pseudo-random password generated by said CPU does 
not match said pseudo-random password generated by 
said security subsystem. 

14. The computer security system of claim 10 further 10 
including 

(n) means for said security subsystem to retrieve at least 
one other security subsystem's public key, where said 
other security subsystem is attached to another com- 
puter which is connected to said computer by a com- 15 
puter network; and 

(o) means for said security subsystem to create a copy of 
said special use security parameters file encrypted with 
said other security subsystem's public key and to store 
it on said special use token so the token can be securely 20 
used on said the other computer. 

15. The computer security system of claim 10 further 
including 

(n) means for said security subsystem to transmit said 
public key to at least one other security subsystem is 25 
attached to another computer which is connected to 
said computer by a computer network; 

(0) means for said security subsystem to retrieve said 
other security subsystem's public key; 

(p) means for said security subsystem to encrypt a net- 30 
work security parameters change file first using said 
other security subsystem's public key and second with 
said private key and to transmit said network security 
parameters change file to said other security subsystem; 
and 35 

(q) means for said other security subsystem to implement 
the security provisions required by network security 
parameters change file after it has been successfully 
authenticated by decryption using first said public key 
and using second said other security subsystem's pri- 40 
vate key. 

16. The computer security system of claim 8 further 
including 

(g) means for said security subsystem to store in said 
restricted memory a list of identifying characteristics of 45 
authorized programs that may be run by said CPU; 

(h) means for said security subsystem to restrict access to 
said authorized programs under such conditions as have 
been predefined in said security program, and said 
general security parameters. 

17. The computer security system of claim 8 further 
including 

(g) meaas for said security subsystem to store a copy of 

a certified transaction public key in said restricted 55 
memory; 

(h) means for said security subsystem to encrypt a self- 
identifying message including a copy of said public key 
using said certified transaction public key; 

(1) means for transmitting said encrypted self -identifying 60 
message to the certifying authority who issued said 
certified transaction public key; 

(j) means for receiving from said certifying authority a 
unique digital certificate for an anonymous party pri- 
vate key encrypted with said public key; 55 

(k) means for said security subsystem to store said unique 
digital certificate in said restricted memory; and 
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(1) means for said security subsystem to retrieve said 
unique digital certificate from said restricted memory 
and to transmit it to as required by said security 
program and general security parameters to other com- 
puters connected with said computer by means of a 
network. 

18. The computer security system of claim 8 further 
including: 

(g) means for storing a copy of single site licensing public 
key in a secure memory location of said security 
subsystem; and 

(h) means for requiring said security subsystem to identify 
a new program to be installed on said computer that is 
subject to the single site licensing requirements defined 
in said security program by decrypting a digital cer- 
tificate provided with said new program using said 
single site licensing public key and implementing said 
single site licensing requirements relative to said new 
program upon verification of said digital certificate. 

19. The computer security system of claim 18 further 
including: 

(i) means for said security subsystem to extract from said 
digital certificate site license parameters defining at 
least one limitation on the use of said new program; and 

(j) means for requiring said security subsystem to deny 
requests by said computer to access said new program 
whenever said access requests violate said site license 
parameters. 

20. The computer security system of claim 8 further 
including: 

(g) means for said security subsystem to transmit said 
public key to the software vendor of a site restricted 
program; 

(h) means for said security subsystem to receive a site 
license certificate encrypted with said public key from 
said software vendor; 

(i) means for said security subsystem to verify the authen- 
ticity of said site license certificate by decrypting said 
site licence certificate with said private key; and 

(j) means for requiring said security subsystem to deny 
requests by said computer to access said site restricted 
program whenever said site license certificate has not 
been received and verified. 

21. The computer security system of claim 8 further 
including: 

(g) means for said security subsystem to create a special 
use identification file encrypted with said public key 
that contains at least a copy of a special use identifi- 
cation code and to write by means of said token 
read/write device said special use identification file to 
a special use token; 

(h) means for said security subsystem to store a copy of 
said special use identification code and special use 
security parameters assigned to said special use iden- 
tification code in a restricted memory location; and 

(i) means for said security subsystem to retrieve said 
special use identification file from said special use 
token when said special use token is inserted into said 
token read/write device and to decrypt the file using 
said private key and to thereby retrieve said special use 
identification code and said special use security param- 
eters and to limit access requests by said computer to 
said peripheral and storage devices for a period of time 
and under such conditions as provided by said security 
program and said special use security parameters. 
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22. The computer security system of claim 10 further 
including: 

(j) means for said security subsystem to retrieve said 
special use private key from said special use token and 
to decrypt files that have been encrypted using said 
special use public key. 
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23. The computer security system of claim 10 further 
including: 

(j) means for said security subsystem to retrieve said 
special use private key from said special use token and 
to encrypt files using said special use private key. 
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